\chapter{Literature Review}
\section{Definition of Research Base}
\vspace{-4mm}
Following the DS approach \parencite{Hevner2004}, the knowledge base provides the raw material from which IS research is accomplished. By taking up this idea, the collection of raw materials for measuring service granularity within a SOA can be accomplished by means of a literature review of research contributions with the objective to achieve a maximum transparency of the current state of research.
\newline
\noindent
In the upcoming sections, the design of the executed literature review is explained. Generally, the aim was to collect contemporary and valuable research contributions, as they reflect the current state of research best.
\newline
\noindent
As already mentioned in the introduction section, there are lots of publications mentioning SOA design principles to be  followed with respect to SOA initiatives. Moreover, service granularity is often mentioned as crucial parameter to steer projects into a desired direction guaranteeing Business-IT alignment. However, measuring service granularity, meaning the quantification of service granularity and its dependent parameters (cohesion, coupling), is rarely researched.
\newline
\noindent
To achieve the previously explained objective, a structural search in \textit{Science Direct}\footnote{Accessible over http://www.sciencedirect.com}, \textit{ACM}\footnote{Accessible over http://dl.acm.org} and \textit{EBSCO}\footnote{Accessible over http://search.ebscohost.com} has been executed and any contribution matching the search terms are collected without taking the publication date into consideration. With regard to quality characteristics, the search contains only peer-reviewed journal articles and  inproceedings. The search was executed on 6th of May 2012.

\begin{table}[ht]
		\begin{center}
	    	\includegraphics[page=9, trim=6.41cm 2.19cm 5.8cm 0.32cm, keepaspectratio=true, scale=0.7, clip=true]{graphics/approach}
			\caption[Quantitative overview literature review]{Quantitative overview literature review}
			\label{Quantitative overview literature review}
		\end{center}
\end{table}
 
\noindent
As seen in table \ref{Quantitative overview literature review}, research contributions have been collected out of three databases. To cover relevant research contributions, two search terms have been defined, whereas a logical \textit{AND} condition is used to connect them. In order a research paper is considered in the result set, shown in row ``Papers from databases'', both search terms must be jointly fulfilled and be present in the \textit{ABSTRACT} field of the relevant paper. Considering the search terms, shown in table \ref{Quantitative overview literature review}, the following points are of interest:

\begin{itemize}
  \item \textbf{Search Term I}\newline
  SOA is seen as the general topic in the context of the thesis. Hence, multiple wordings of SOA are considered in the first search term.
  \item \textbf{Search Term II}\newline
  Because the objective is to measure service granularity with respect of its dependent parameters, the second search term covers related keywords. By means of metrics, (in)dependant parameters can be quantified. With respect of granularity, there is the synonym ``coarseness" sometimes used. In addition, the level of granularity is often expressed as ``fine" or ``coarse". Moreover, ``coupling" and ``cohesion" are seen as the dependent parameters and need therefore to be considered in the search. ``SOA  health" is interesting to find out methods improving the SOA health. Last but not least, to guarantee a complete picture regarding internal structural software attributes ``complexity measurement" is in place.
\end{itemize}

\noindent
After executing the search in three databases, 217 papers in total were found. Further six papers have been collected out of a free text-search in the internet. On the basis of 223 papers, backward- and forward-research was executed to find further appropriate contributions. Worth mentioning in this regard is, that particularly the most relevant papers have been checked back and forth to either identify the basis of research or the most contemporary ways of measuring service granularity.

\section{Identification of relevant Research}
\vspace{-4mm}
Referring to table \ref{Quantitative overview literature review}, out of 247 papers in total, 31 papers have been marked relevant, thus defining the ``Research Basis''. In order to further focus on the content, these papers have been marked, either as ``mentioned'' or ``elaborated'', as seen in table \ref{Overview of research basis}. With respect to the papers  marked as ``mentioned'', the content of these papers give essential indications around service granularity and its dependent parameters. Following the objective of this thesis to measure service granularity within a SOA, papers marked as ``elaborated'' answer concrete questions regarding approaches to measure by means of metrics particular criteria. In addition, because of the diverse spectrum reflected in the ``Research Basis'', the 31 papers have been categorized as follows:

\begin{itemize}
  \item \textbf{Focus on Service Granularity}\newline
Service granularity is seen as an important  parameter in the context of SOA initiatives.  This category contains research contributions focusing on service granularity.
  \item \textbf{Focus on Internal Software Attributes}\newline
As mentioned earlier, service granularity influences internal structural software attributes, such as coupling, cohesion and complexity. This category contains papers, reflecting characteristics of internal software attributes in the context of SOA.
  \item \textbf{Focus on External Software Attributes}\newline
Internal software attributes influences external software attributes. This category focuses on research contributions dealing with external structural software attributes in the context of SOA. 
  \item \textbf{Relation between Service Models and Service Granularity}\newline
Within SOA best-practice approaches various service models are foreseen within a service layering framework. This category contains papers, which address the need of different service granularity degrees, depending on the service layer, where service resides.
   \end{itemize}

\begin{table}[ht]
		\begin{left}
	    	\includegraphics[page=10, trim=0cm 4.58cm 2.4cm 0.0cm, keepaspectratio=true, scale=.608, clip=true]{graphics/approach}
			\caption[Overview of research basis]{Overview of research basis}
			\label{Overview of research basis}
		\end{left}
\nocite{High2008} \nocite{Li2010} \nocite{Papazoglou2002} \nocite{Shanmugasundaram2012} \nocite{Pautasso2009} \nocite{WeberJahnke2009} \nocite{Barnickel2010} \nocite{Demirkan2008} \nocite{HockKoon2010} \nocite{Mateos2010} \nocite{Ribeiro2011} \nocite{Feuerlicht2004} \nocite{Erradi2007} \nocite{Alahmari2010} \nocite{XuQianHe2006} \nocite{Karthikeyan2012} \nocite{Perepletchikov2005} \nocite{Perepletchikov2007} \nocite{Hofmeister2008} \nocite{Hirzalla2009} \nocite{Ma2009} \nocite{XiaoJun2009} \nocite{Perepletchikov2010} \nocite{Rostampour2010} \nocite{Alahmari2011} \nocite{Athanasopoulos2011} \nocite{Feuerlicht2011} \nocite{Kazemi2011a} \nocite{Sindhgatta2009} \nocite{Kazemi2011b} \nocite{Zarrin2011}	
\end{table}   

\noindent
Summarizing table \ref{Overview of research basis}, today's research contributions elaborate concepts of measuring characteristics, such as service granularity, internal- and external structural software attributes. Worth mentioning is, that only a minor number of research contributions elaborate concepts around service granularity and external software attributes.  Moreover, with respect to the category ``Relation between Service Models and Service Granularity'' a research gap can be recognized. Despite \textcite[p. 303]{Feuerlicht2004}, \textcite[p. 610]{Erradi2007} and \textcite[p. 615]{Alahmari2010} state that either the complexity of the service, the service's layer or the service model itself influence service granularity, none of  these contributions elaborate on these hypothesis.
\newline
\noindent 
Because service models differ regarding purpose and scope, thus also influencing service granularity, a relationship between service models and service granularity respectively internal software attributes may be given. This allows evaluations by means of metric suites measuring service granularity and internal structural software attributes of identified or implemented services towards characteristics originating from service models. In the footsteps of \citeauthor*{Hevner2004}'s approach, the applicable knowledge is now made  transparent by analyzing all ``elaborated'' marked papers, listed in table \ref{Overview of research basis}, to later on in a following chapter of this thesis design an artifact addressing the rarely researched area previously pointed out. Therefore, in the next section, an analysis of relevant research contribution is done to bridge foundational concepts with the design of an artifact, which aims to become part of the research gap.
\newline
\noindent
The reflection of the ``Research Basis" foresees an analysis of all ``elaborated'' marked papers per category in ascending order by publication date. Furthermore, the reflection either covers formulas with a short indication about ranges and interpretation or only a listing of the approach due to the voluminous content in the papers. In addition, sometimes are only interesting aspects of papers mentioned, missing an overall summary as already addressed in other contributions. Considering the research of external structural attributes, a further literature research could be executed in future, as the literature review executed for this thesis aims to collect information around the relation between service granularity and internal software attributes.

\section{Analysis of relevant research}
\vspace{-4mm}
\subsection{Focus on service granularity}
\vspace{-4mm}
\subsubsection{Introduction}
\vspace{-4mm}
During the design phase of services, design principles should be adhered. In combination with service granularity, the principle of \textit{service abstraction} is of special interest. According to \textcite[p. 212]{Erl2008}, the fundamental purpose of this principle is to avoid the ``proliferation of unnecessary service information''. In other words, only information should be published by a service contracts, which consumers must know. Moreover, as granularity from a consumer view is often related to the service contracts  (interface), the principle of \textit{service contracts} should be followed, ``to enable designed services with a meaningful level of interoperability'' \parencite[p. 130]{Erl2008} and to improve understandability of contracts as consistency is increased by the use of common contract design standards.
\subsubsection{\textcite{Karthikeyan2012}}
\vspace{-4mm}
Considering \textcite[p. 377]{Karthikeyan2012}, granularity is the communication level associated with some aspect of program design. \textit{Fine-grained} services encapsulate small amount of service logic and transact a rather small volume of data, whereas \textit{coarse-grained} services encapsulate a big amount of service logic and transact a rather big volume of data.

\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[page=13, trim=0cm 3.83cm 0cm 9cm, keepaspectratio=true, scale=0.636, clip=true]{graphics/approach}
			\caption[Formulas to measure service granularity (\cite{Karthikeyan2012})]{Formulas to measure service granularity (\cite{Karthikeyan2012}); \underline{S} is a service composed of a set of services {S1, S2, S3, \ldots Sn}. \underline{O} represents the set of operations belonging to each service Si. \underline{CL} defines the Composite Level. \underline{NAS} defines the number of atomic services in S, whereas \underline{N} defines the total number of services orchistrated by S. Range between 0 - 1. The lower the CL value, the minor the number of  orchistrated services containing parts of service logic addressed by S. \underline{FR} defines the functional richness. N is the total number of services in S, whereas \underline{FCi} defines the function point count of each invoked service on the given operation. \underline{CRUD (Oi)} is set to 1, if it is a CRUD operation in Si. \undelrine{On(Si)} is the total number of operations in Si. Range between 0 - 1. The service is said to be ``rich'', if the FR(S) is close to 1 and above, as no or only a minor number of other operations (except CRUD) are necessary to support its service logic exposed to its consumers. \underline{IG} defines the granularity of the interface. \underline{nip}, \underline{nop} define the number of input, respectively output parameters. \undelrine{Wi} is the defined weight value for parameters (void=0; primitive=0.25; user defined=0.5; complex=1). Range between 0-1. The lesser the IG value, the finer-grained the interface granularity. \undelrine{G(S)} defines the overall granularity of a service. Range between 0-1. The lesser the value, the fine-grained the service granularity.}
			\label{FormulasKarthikeyan2012}
		\end{center}
\end{figure}
\noindent
\textcite[p. 379]{Karthikeyan2012} conclude, that a measure of service granularity cannot be a single measure. Therefore, to evaluate service granularity, a quantification of the \textit{composite level}, {functional richness} and \textit{interface granularity} is required, as defined in figure \ref{FormulasKarthikeyan2012}. Worth mentioning is, that \textcite[p. 380]{Karthikeyan2012} mentioned the threshold values related to service models. The optimal granularity G(S) according them is for \textit{Business} services $G(S) \geq 0.7$, \textit{Domain} services $0.31 \leq G(S) \leq 0.69$ and for \textit{Task} services $0 \leq G(S) \leq  0.30$.
\subsection{Focus on internal software attributes}
\vspace{-4mm}
\subsubsection{Introduction}
\vspace{-4mm}
Papers assigned to this category focus on internal software attributes in the context of SOA. It has been observed, that coupling, cohesion and complexity are the most essential internal structural software attributes in the context of SOA. Table \ref{Detailed overview of research contributions focusing on internal software attributes} aims to outline the relevant papers in this category, with respect to its main focus.

\begin{table}[ht]
		\begin{center}
	    	\includegraphics[page=11, trim=0cm 7.66cm 9.15cm 0cm, keepaspectratio=true, scale=.608, clip=true]{graphics/approach}
			\caption[Detailed overview of research contributions focusing on internal software attributes]{Detailed overview of research contributions focusing on internal software attributes}
			\label{Detailed overview of research contributions focusing on internal software attributes}
		\end{center}
\end{table}
\subsubsection{\textcite{Perepletchikov2005}}
\vspace{-4mm}
By means OO-specific CK metrics \parencite{Chidamber1994} and McCabes CC and LOC metric \parencite{McCabe1994}, one of the first attempts to measure internal structural software attributes in the context of SOA turned out that some of the existing  OO-specific metrics are inapplicable in the context of SOA  \parencite{Perepletchikov2005}.
\newpage
\subsubsection{\textcite{XuQianHe2006}}
\vspace{-4mm}
Considering the fact of having completely independent, stateless, and self-contained service components, the composition of such service components result in low coupling \textcite[p. 171]{XuQianHe2006}. However, for transaction-oriented business processes, services need transaction states either in cache or in permanent storage. Therefore, \textcite{XuQianHe2006} recommend a set of service dependency coupling metrics, shown in figure  \ref{XuQianHe2006FormulasA}.
\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[page=14, trim=0cm 2.54cm 8.08cm 14.52cm, keepaspectratio=true, scale=0.6, clip=true]{graphics/approach}
			\caption[Formulas to measure service dependency coupling (\cite{XuQianHe2006})]{Formulas to measure service dependency coupling  (\cite{XuQianHe2006}); \underline{DSD} defines the Degree of State Dependency, whereas n defines the total number of components in the domain and k represents the component. Ck=1 if the component k has its states, otherwise Ck=0. Range between 0-1. The lower the DSD, the looser is the state dependency coupling between service components. \underline{DPD} defines the degree of Persistent Dependency. Pij=1, if service component i participates the persistent data j is sharing, otherwise Pij=0; n defines the number of service components in the domain and m is the number of various persistent repositories. Range between 0-1. The lower the DPD is, the looser the coupling may be. \underline{ARSD} defines the Average Required Service Dependency; n is the total number of components in the domain; Ri is the number of required service components i requires providing its services. Range between 0-1. The lower the ARSD value is, the looser the coupling is among the components.	
			}
			\label{XuQianHe2006FormulasA}
		\end{center}
\end{figure}
\noindent
Worth mentioning is, that the CL metric, defined by \textcite{Karthikeyan2012}, has similar intentions like the \textit{Average Required State Dependency} (ARSD)  \parencite{XuQianHe2006}. Both metrics reveal an indication about the degree of which a service requires other services to fulfill its service logic.
\begin{figure}[h]
		\begin{center}
	    	\includegraphics[page=15, trim=0cm 9.81cm 10.01cm 6.37cm, keepaspectratio=true, scale=0.6, clip=true]{graphics/approach}
			\caption[Formulas to measure service invocation coupling (\cite{XuQianHe2006})]{Formulas to measure service invocation coupling  (\cite{XuQianHe2006}); \underline{ASIC} defines the Average Service Invocation Coupling; \underline{ICi} defines the invocation coupling for component i; \underline{n} is the total number of components in the domain; \underline{Wi,async and Wi,sync} is the weight of asynchronous operations respectively synchronous operations, whereas \underline{Ni,async and Ni,sync} defines the numbers of asynchronous operations respectively synchronous operations.}
			\label{XuQianHe2006FormulasB}
		\end{center}
\end{figure}
\noindent
Going further, particularly with the launch of \textit{message oriented middleware} (MOM) systems, asynchronous invocations became popular, because of lower coupling between service consumer and service requester compared to synchronous invocations. \textcite[p. 172]{XuQianHe2006} even states, that the lower the \textit{Average Service Invocation Coupling} (ASIC), outlined in figure \ref{XuQianHe2006FormulasB}, is, the better the system performance in terms of time and maintainability.
\subsubsection{\textcite{Perepletchikov2007}}
\vspace{-4mm}
Due to the fact that SO systems are often developed in an ad-hoc fashion without evaluating alternative design options, quality gets negatively impacted particularly with respect of maintainability. Because also cohesion influences maintainability of software products, \textcite[p. 328]{Perepletchikov2007} introduces a set of design-level metrics for evaluating different types of cohesion, as seen in figure \ref{Perepletchikov2007Formulas}.

\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[page=16, trim=0cm 6.50cm 7.84cm 6.38cm, keepaspectratio=true, scale=0.636, clip=true]{graphics/approach}
			\caption[Formulas of cohesion metrics  (\cite{Perepletchikov2007})]{Formulas of cohesion metrics (\cite{Perepletchikov2007}); \underline{SIDC} defines Service Interface Data Cohesion and quantifies cohesion based on common parameters, reflected in the service contract, of operations belonging to a service. ``A service is deemed to be highly cohesive when all service operations work on the same input parameter types''. Range between 0-1. The higher SIDC is, the stronger is the cohesion. \underline{SIUC} defines Service Interface Usage Cohesion and measures cohesion based on the number of operations used by clients. ``A service is deemed to be highly cohesive when all service operations are invoked by every client''. Range between 0-1. The higher SIUC is, the more operations are used by consumers using the respective service. Worth mentioning thereby is, that \underline{SSUC} can be seen as an add-on to SIUC measuring the sequential cohesion of a service by counting the number of operations whom's output is a precondition for an other operation belonging to the same service.  \underline{SSIC} defines Strict Service Implementation Cohesion and quantifies cohesion based on the number of associated service components used by operations belonging to the respective service. ``A service is deemed to be highly cohesive when all service operations are implemented by the same implementation elements. Range between 0-1. The higher SSIC is, the more probable it is, that operations use a minor set of service components to perform their service logic. \underline{LSIC} defines Loose Service Implementation Cohesion and considers on top of SSIC indirectly connected implementation elements. \underline{TICS} defines Total Interface Cohesion of a Service and is based on an average of the previously defined cohesion metrics. Worth mentioning in this regard is, that IMPC (Implementation Cohesion) is based either on SSIC or LSIC depending on project requirements.}
			\label{Perepletchikov2007Formulas}
		\end{center}
\end{figure}
\noindent
With respect of the results of these metrics, the purpose of these metrics is twofold. Firstly, they can be used as a quantitative estimator for cohesion of services. Secondly with respect to SOM, they can be used to predict maintainability of service candidates.
\newpage
\subsubsection{\textcite{Hofmeister2008}}
\vspace{-4mm}
Originating from a concept, named \textit{Business Process Integration Oriented Application Integration} (BPIOAI) \parencite{Linthicum2004}, which recommends the design of placing the control model outside of the participating application systems, whereas orchestration platforms serves technically as control instance over multiple distributed systems and business-wise as a back-end for business processes, \textcite{Hofmeister2008} define multiple metrics to support design decisions in such an environment.
\newline
\noindent
With respect of the metrics, an optimal mechanism, following \textcite{Hofmeister2008}, would be a boolean discriminant function (BDF) to determine the modifiability of a system. This seems to be unrealistic, as it is cost intensive due to the fact that a real application beyond scientific prototyping must be developed to support such an initiative. Moreover, lots of subjective, qualitative decisions  are taken, which cannot be addressed in a BDF. However, this metrics can be used to ``highlight certain aspects for service-oriented design principles and their impact on modifiabiltiy. This is why a qualitative description of inter-relations among the metrics is considered better applicable than a quantitative discriminant function'' \parencite[p. 198]{Hofmeister2008}.
\begin{figure}[H]
		\begin{center}
	    	\includegraphics[page=17, trim=0cm 3.46cm 4.69cm 0cm, keepaspectratio=true, scale=0.68, clip=true]{graphics/approach}
			\caption[Formulas of cohesion and complexity metrics  (\cite{Hofmeister2008})]{Formulas of cohesion and complexity metrics (\cite{Hofmeister2008}); \underline{COS} defines the Coupling of Service based on the count of services a given service calls operations on. Range between $0-\infty$. Cos represents the number of services a given service composes. \underline{SCF} defines the Service Coupling Factor and represents the coupling between a set of services compared to the maximal possible coupling of these services. Range between 0-1. The higher SCF is, the more coupled a set of services is. \underline{SSC} defines the System's Service Coupling and relates the consumer coupling ``with the maximum coupling in a system if no aggregators were used''. Range between 0-1. The higher SSC is, the more probable is interaction between services without mediation. \underline{EOA} defines the Extent of Aggregation based on the count of channels between ``non-aggregative consumers and aggregators with the overall count of channels from non-aggregative consumers to arbitrary service providers''. Range between 0-1. The higher EOA is, the more probable is a high degree of aggregation among the services. \underline{SCZ} defines the extent of a system's centralization. Range between 0-1. The higher SCZ is, the more centralization is in a system. \underline{DOA} defines the Density of Aggregation based on the number of receive-ports with the total number of ports. Range between 0-1. A DOA higher than 0.5 reflects, that the service consumes more than it receives. \underline{ACZ} defines the Aggregator Centralization and incorporates the idea of centralization and density of aggregation. Range between 0-1. ``ACZ describes to which degree a system mediates service calls and interprets the use of few aggregators as a centralization''. 
}
\label{Hofmeister2008Formulas}
\end{center}
\end{figure}

\subsubsection{\textcite{Hirzalla2009}}
\vspace{-4mm}
Referring to SOMA \parencite{Arsanjani2008} as well as other decomposition approaches, \textcite{Hirzalla2009} states, that such approaches do not deal with the resulting underlying complexity of services. Therefore, this paper defines ten metrics (table \ref{Hirzalla2009Metrics}), divided into two groups, \textit{Design-time} and \textit{Run-time}, to figure out complexity characteristics of a SOA solution.

\begin{table}[ht]
		\begin{center}
	    	\includegraphics[page=2, trim=1.6cm 9cm 1.6cm 10.2cm, keepaspectratio=true, scale=1, clip=true]{graphics/hirzella}
			\caption[Metrics evaluating flexibility and complexity (\cite{Hirzalla2009})]{Metrics evaluating flexibility and complexity (\cite{Hirzalla2009})}
\label{Hirzalla2009Metrics}
\end{center}
\end{table}
\noindent
\textbf{Design-Time Metrics}
\newline
\noindent
WSIC can be a first indicator of complexity in a SOA, due to the fact, that services exposing multiple operations are more complex. Reasons are the amount of work required for delivery (design, develop and test), higher efforts for monitoring (fulfillment of SLAs per exposed operation) and performance and problem determination as with more operations data structure and internal alignment between operations is required \parencite[p. 44]{Hirzalla2009}.
\newline
\noindent
The SS metric can be derived out of the \textit{Web Services Resource Framework} (WF-RF) or \textit{WS-Context} and calculated by means of the following formula: SS = SLS / (SLS + SFS\footnote{SFS \ldots stateful Services}). By means of this metric, the service design principle statelessness, promoting for stateless (SLS) services, can be adhered.
\newline
\noindent
Another metric mentioned by \textcite[p. 45]{Hirzalla2009} is SST, relating transaction-aware services (TAS) in relation to the overall number of services, including \textit{non-transaction-aware}  (NTAS) services. As complexity driver is the implementation of transaction support  (including compensation logic) seen.
\newline
\noindent
With respect to NHT, the fraction of human tasks (HT) is related with the number of automated tasks (AT). According to \textcite[p. 47]{Hirzalla2009}, a high number of human tasks decrease the flexibility of a SOA solution.
\newline
\newline
\noindent
\textbf{Run-Time Metrics}
\newline
\noindent
Reflecting the run-time metrics, with the increase of the number of services (NOS), complexity within a SOA increases, as an increase of coordination (governance and service life-cycle management) and additional infrastructure requirements (in particular scalability) are required \parencite[p. 47]{Hirzalla2009}.
\newline
\noindent
With respect of SCP, reflecting the friction of services composing others, increased complexity is seen in the area of choreography as no central entity controls the process \parencite[p. 47]{Hirzalla2009}.
\newline
\noindent
SAM outlines the fraction of  services using a virtualization layer in respect to services using a point to point access. By means of \textit{Enterprise Service Bus} (ESB) technologies, flexibility can be increased, as ESBs facilitate virtual access methods \parencite[p. 48]{Hirzalla2009}.
\newline
\noindent
Referring DSSS, the fraction of services selected dynamically compared to the total number of services in a SOA, the more dynamic selection of services takes place, the more complex and flexible the SOA becomes \textcite[p. 48]{Hirzalla2009}.
\newline
\noindent
Referring to SRP, the principle of composability can be associated. \textit{Indirect Exposure} increases flexibility, as underlying components are abstracted, but further management effort is required to guarantee functioning of composed components.
\newline
\noindent
Last but not least, the more versions of a service exist (NOVS), the more complex the SOA solution becomes.

\subsubsection{\textcite{Ma2009}}
\vspace{-4mm}
Because the identification of services with the correct level of abstraction from business process decomposition is seen as one key activity, \textcite[p. 162]{Ma2009} suggest an approach of measuring various characteristics of identified services. This requires a three-phased approach, consisting of the phases modeling, measuring and evaluating, as seen in figure \ref{Ma2009}.

\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[page=3, trim=2cm 20.3cm 11.2cm 2.5cm, keepaspectratio=true, scale=1.3, clip=true]{graphics/ma}
			\caption[Overview of the measurement approach for service identification (\cite{Ma2009})]{Overview of the measurement approach for service identification (\cite{Ma2009})}
\label{Ma2009}
\end{center}
\end{figure}

\noindent
With respect to the phase modeling, a service portfolio captures the architectural elements from business process decomposition. Worth mentioning is, that the overall approach is an integral approach covering architectural elements from the business process and its related software services. In the measuring phase, service granularity, coupling, cohesion and entity convergence are calculated, based on the formulas defined in \textcite[p. 163-165]{Ma2009}, for all identified services. Worth mentioning in this respect is, that the modeling and measuring phase can be multiple times repeated to get multiple partitions of services fulfilling the to be implemented business process.  In the evaluation phase, the results multiple partitions are evaluated to find an optimal solution to carry on with the implementation of the services.

\subsubsection{\textcite{Sindhgatta2009}}
\vspace{-4mm}
This paper elaborates practical metrics to address cohesion and coupling, as seen in figure \ref{Sindhgatta2009Formulas}.

\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[page=21, trim=0cm 14.37cm 8.06cm 0cm, keepaspectratio=true, scale=0.55, clip=true]{graphics/approach}
			\caption[Formulas to measure coupling and cohesion  (\cite{Sindhgatta2009})]{Formulas to measure coupling and cohesion(\cite{Sindhgatta2009}); \underline{SFCI} defines Service Functional Cohesion Index based on the fraction of commonality of used messages and the total number of operations of a service. Range between 0-1. The higher the SFCI, the higher the functional cohesion of a service. \underline{SOCI} defines the Service Operational Coupling Index and represents the number of invoked operations (belonging to other services) by a given service s. \underline{ISCI} defines the Inter-Service Coupling and represents a count of used services by  a given service s. \underline{SMCI} defines the Service Message Coupling Index and represents the count of messages received and sent. The lower the SMCI, the lesser the coupling.}
\label{Sindhgatta2009Formulas}
\end{center}
\end{figure}

\subsubsection{\textcite{XiaoJun2009}}
\vspace{-4mm}
Relating \textcite[p. 1]{XiaoJun2009}, to evaluate and enhance the quality of SO systems, there is a need to quantify structural quality attributes to provide signs of design anomaly to software engineers. However, finding a metric model, capable of quantifying overall system qualities and applicable in early development phases is difficult. Reasons are firstly a lack of precise definitions of quality attributes, secondly a lack of transformation of quality characteristics into measurable indicators and thirdly difficulties in the identification of to be exposed information to service consumers to evaluate services from consumer perspective. Similar as \textcite{Hofmeister2008}, \textcite{XiaoJun2009} proposes the construction of a graph to identify dependencies between services and clients. Due to the fact, that information theory turned out to be the basis to compute size, complexity and coupling \parencite{Allen2007}, a set of initial formulas based on \textit{information entropy} are defined to calculate the extent of \textit{common use of service operations} (CUSO) by clients of a service. As seen in previously mentioned research contributions, services are deemed to be cohesive if all operations belonging to a service are invoked by clients using the service. With respect to CUSO, the idea is to measure a valid design strategy, intending to group operations, that are used together in a single service, in order the mutual information content between the functionally related operations and the services is maximized.

\subsubsection{\textcite{Perepletchikov2010}}
\vspace{-4mm}
Following up on \textcite{Perepletchikov2007}, an empirical evaluation of previously defined metrics (SIDC, SIUC, SSUC, SSIC, LSIC, TICS) have been executed. The statistical tests have shown, that the proposed metrics can be applied in the initial design phase of a new system and in the maintenance of a given system \parencite[p. 101]{Perepletchikov2010}. In the former, maximizing TICS (values close to one underpin high cohesion) improves the analyzability of the system, as services and its operations are ideally cut. Moreover, by evaluating quality attributes at design time, a decrease of total lifetime cost of a system is seen. Last but not least with respect to maintenance, the metrics can also be used to identify ``refactoring'' potential in case the TICS value falls below a specific threshold, which can be defined by projects themselves.
\newline
\noindent
However, \textcite{Perepletchikov2010} states on the basis of \textcite{Eder92}, that a sole consideration of cohesion does not yield the intended results, as coupling is seen as a conflicting factor. ``Therefore one of the major challenges of SO design is to find a balance between system-level coupling and service-level cohesion'' \parencite[p. 102]{Perepletchikov2010}.
\newpage
\subsubsection{\textcite{Rostampour2010}}
\vspace{-4mm}
Inspired by the entity-centric process modeling approach \parencite{Khoshnevis2009},  \textcite{Rostampour2010} define a novel approach for measuring cohesion of services designed based on an \textit{entity-centric} design approach. Although previously mentioned cohesion metrics consider common input and output parameters of services, they do not consider inter-relations, such as shared or unshared parameters (entities) between operations of the service. As seen from former hypothesis regarding cohesion, also \textcite[p. 1]{Rostampour2010} states that services encapsulating its related entities results in high cohesion. On the other hand, if services are related to multiple business entities, service reuse gets cumbersome if no obvious relatedness between the involved parameters can be observed in the service contract. Especially when dealing with multiple business entities in a service, whereas not every business entity is part of every operation signature, reflected in a simplified example in \ref{Rostampour2010}, these metrics \parencite[p. 3]{Rostampour2010} improve the cohesion determination as implicit connection of business entities are considered.

\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[page=18, trim=0cm 7.76cm 0cm 0cm, keepaspectratio=true, scale=0.55, clip=true]{graphics/approach}
			\caption[Formulas to measure conceptual cohesion (\cite{Rostampour2010})]{Formulas to measure conceptual cohesion  (\cite{Rostampour2010}); \underline{ECF} defines the Explicit Connection Factor. Range between 0-1. The higher ECF is, the more entities are shared among the operations of a service. \underline{B} denotes the number of business entities not shared between all operations. \underline{ICF} defines the Implicit Connection Factor and represents the fraction between implicit connection of business entities and the total number of connection between business entities. Range between 0-1. The lower ICF is, the more implicit connections exists between operations and business entities. \underline{CCF} defines the Comprehensive Cohesion Factor and denotes cohesion between two operations considering ECF and ICF. Range between 0-1. A high value of ECF represents a high level of cohesion between two operations. \underline{CCM} defines the Comprehensive Cohesion Metric and represents the degree of cohesion including all operations of a service. Range between 0-1. A high CCM corresponds a high degree of cohesion of a service.}
\label{Rostampour2010}
\end{center}
\end{figure}
\newpage
\subsubsection{\textcite{Alahmari2011}}
\vspace{-4mm}
As service granularity indirectly influences design qualities like flexibility, reusability and performance, this research contributions aims to measure service granularity and its impacted structural software attributes, such as complexity, cohesion and coupling from a service provider's perspective. Basically the proposed metrics, as shown in figure \ref{Alahmari2011} outline measure on operation-, service- and system-wide-level.

\begin{figure}[H]
		\begin{center}
	    	\includegraphics[page=19, trim=0cm 6.62cm 6.64cm 0cm, keepaspectratio=true, scale=0.65, clip=true]{graphics/approach}
			\caption[Formulas to measure service granularity, cohesion and coupling  (\cite{Alahmari2011})]{Formulas to measure service granularity, cohesion and coupling (\cite{Alahmari2011}); \underline{ODG} defines the Operation Data Granularity. FPW and CPW are the assigned weights for input respectively output parameters. FP and CP are functions to sum the total weight of all input- respectively output parameters over all operations belonging to a service. Range between 0-1. The lower the ODG, the lower the data granularity of the operation's interface. \underline{OFG} represents the Operation Function Granularity. OT defines the weight value for the operation, whereas O is a function computing the total weight of the service's operations. Range between 0-1. The lower the OFG, the lower the functional granularity. \underline{SOG} defines the Service Operation Granularity. Granulation levels can be seen in table on the right. \underline{ASOG} defines the system-wide Average Service Operation Granularity. The complexity of a service is related with the service granularity, as defined in Average Service Operation Complexity (ASOM). \underline{SOC} defines the Service Operation Cohesion, with a range from 0 to unity. The lower the SOC, the more cohesion between the operations of a service; the lower the complexity. A system-wide cohesion evaluation can be done by means of Average Service Operation Cohesion (\underline{ASOC}). Range between 0-1. The lower the ASOC, the more cohesive services are in a SOA. \underline{ASOU} defines the Service Operation Coupling based on the number of (a)synchronous services in a domain [NS equals number of services in the domain]. The lower the ASOU, the lower the coupling between services in a domain.}
\label{Alahmari2011}
\end{center}
\end{figure}

\subsubsection{\textcite{Athanasopoulos2011}}
\vspace{-4mm}
An interesting approach detecting communicational and sequential cohesion is elaborated based on a generic conceptual model for serviced, derived from the \textit{W3C} standard services architecture. The metrics, \textit{Lack of Sequential Coupling} ($LoC_s$) and \textit{Lack of Communicational Coupling} ($LoC_c$) find out similarities of parameters in services' input and output messages based on a comparison of tree-elements. This is probably leads to an overestimation of cohesion, as stated by \textcite[p. 595]{Athanasopoulos2011}. However, as today's service architectures transmit XML-based information, this approach is applicable to tune any cohesion metric, deriving measures out of input and output parameters within messages.

\subsubsection{\textcite{Feuerlicht2011}}
\vspace{-4mm}
Similar, like in the previous paper, a Data Coupling Index (DCI) metric is proposed, based on the number of shared schema elements for each interface message pair combination \parencite[p. 138]{Feuerlicht2011}. Thus, the level of data coupling can be measured. On top of that, ``the quality of service design based on orthogonality of interface data structures'' \parencite[p. 140]{Feuerlicht2011} can be evaluated.
\newpage
\subsubsection{\textcite{Kazemi2011a}}
\vspace{-4mm}
Bridged from modern \textit{Algebra} information retrieval approaches, this contribution measures conceptual coupling based on \textit{Latent Semantic Indexing} (LSI). Comparing with previously defined metrics, the focus lies on conceptual coupling (semantic relationships between architectural elements), whereas previously mentioned contributions focus on structural coupling (e.g. based on cardinality of composed services). Under the assumption, that a top-down approach is followed to identify services, this approach is seen more effective, as structural coupling metrics use artifacts like sequence and collaboration diagrams \parencite[p. 505]{Kazemi2011a}, which are often not available at time of service identification. An overview of the defined metrics can be seen in figure \ref{Kazemi2011aFormulas}.

\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[page=20, trim=0cm 7.11cm 0.38cm 9.95cm, keepaspectratio=true, scale=0.55, clip=true]{graphics/approach}
			\caption[Formulas to measure service coupling based on Latent Semantic Indexing (\cite{Kazemi2011a})]{Formulas to measure service coupling based on Latent Semantic Indexing (\cite{Kazemi2011a}); \underline{CCO} defines Conceptual Coupling between Operations. Range between 0-1. The higher the CCO is, the higher the conceptual coupling between a pair of operations belonging to a service. \underline{CDSO} defines Conceptual Dependency a service is having to an operation belonging to the same service. Range between 0-1. The higher CDSO, the more conceptually coupled is a service with the respective operation. \underline{CCS} defines Conceptual Coupling of a Service. Range between 0-1. The higher the CCS, the more conceptually coupled is a service to a set of other services.}
\label{Kazemi2011aFormulas}
\end{center}
\end{figure}

\subsection{Focus on external software attributes}
\vspace{-4mm}
\subsubsection{Introduction}
\vspace{-4mm}
Like initially indicated, external structural software attributes are highly influenced by internal structural software attributes, such as cohesion, coupling and complexity. Hence, the foundation to measure external attributes is based on internal attributes, as previously outlined. This is underpinned by \textcite[p. 52]{Zarrin2011}, saying that characteristics such as coupling, cohesion and service granularity directly affect maintainability sub-attributes (according ISO/IEC 9126 analyzability, changeability, stability, testability) and therefore also indirectly maintainability. This is also confirmed by \textcite{Kazemi2011b}, saying that service granularity highly influence the maintenance of a SOA.

\subsubsection{\textcite{Kazemi2011b}}
\vspace{-4mm}
Driven by the fact, that SO analysis and design lack in the provision of a quantitative model for ``service modularity level evaluation'', this paper aims to provide a metric suite to measure the degree of service modularity to predict maintainability of a services. The three aspects covered by the suite are \textit{decomposability}, \textit{composability} and \textit{understandability}.
\newline
\noindent
With respect to the modular decomposability, the objective is to divide an application into services with the objective to ideally encapsulate a single function which could be reused in multiple business process scenarios. The defined metric in this area, under the prerequisite of executing an entity-centric decomposition approach, could be used to find out the amount of focus of a service on a single business functionality \parencite[p. 101]{Kazemi2011b}. Note, the concept is based on conceptual relationship among operations of a service, subtracted by the conceptual relationship the service has to other services in the investigated set of services.
\newline
\noindent
Originating from CBSD, understandability was supported by the provision of meta-information about the component's interface to reduce the effort and the time needed to get to know the concept and applicability behind a component \parencite[p. 213]{Washizaki2003}. ``With respect to services, understandability reflects the ability of a person to understand the functionality of a service with no need to have knowledge about other services'' \parencite[p. 98]{Kazemi2011b}. As a consequence, involved persons such as business analysts or service designers can easier estimate whether the service meets the requirements or scope changes are needed. Aiming to achieve services encapsulating self-contained functionality, the metric for modular understandability of services foresees conceptual dependency determination (between business entities and operations) to finally indicate the degree of understandability.
\newline
\noindent
The degree of composability of services within a SOA is seen as essential factor affecting reuse. The metric for modular composability considers the existence of input and output parameters of operations belonging to a service interface. Obviously, operations with no input and output parameters positively influence the degree composability (operations having in put and output parameters vice-versa) \parencite[p. 99]{Kazemi2011b}. Based on the three previously mentioned indicators, the overall modularity indicator can be computed. Despite the concept shows  meaningful procedures, further studies are required to show its applicability  \parencite{Kazemi2011b}.

\subsubsection{\textcite{Zarrin2011}}
\vspace{-4mm}
This paper recommends a maintainability evaluation model consisting of five sections: \textit{input}, \textit{analysis}, \textit{measurement}, \textit{decision making} and \textit{output}. With respect to the analysis phase, service granularity, cohesion and coupling have been identified as independent parameters influencing maintainability and its sub-attributes (stability, testability, changeability, analyzability).

\section{Discussion of results}
\vspace{-4mm}
\subsection{Introduction}
\vspace{-4mm}
In total 55 metrics, related to service granularity, cohesion, coupling or complexity, have been previously outlined in the literature review. Worth mentioning thereby is, that this thesis primarily deals with ``internals'' as ``externals'' depend on them. Metrics out of the category ``Focus on External Software Attributes'' are not considered within these 55 metrics, because of two reasons. Firstly, this literature review cannot be seen as an holistic review of service granularity and external software attributes. Secondly, this thesis addresses granularity measures in connection with internal attributes, as service granularity in connection with cohesion and coupling is observed to be the basis for any relationship towards external structural software attributes.
\newline
\noindent
To derive results out of the knowledge base, the collected metrics have been related to three criteria, giving hints about the  \textit{type of information used by the metric}, the \textit{evaluated architectural element} and the \textit{source of information}, as seen in table \ref{collective_overview_metrics}.
\newline
\noindent
With respect to the first criteria, structural information in a SOA is collected out of architectural elements such as services, operations, etc.. Typically by the execution of task-centric process modelling approaches, structural information can be fetched out of diagrams (e.g sequence diagrams). In addition, structural information could be fetched from service inventories if existing or from run-time environments (e.g. ESBs) once process implementation is productive. However, when it comes to conceptual information, which make use of concepts such as \textit{Latent Semantic Indexing}, the delivery process foresees entity-centric modelling, enabling the use of conceptual information to possibly derive quality indications with higher \textit{entrophy} \footnote{Worth mentioning is, that conceptual information is used on top of existing structural information. Any metric which makes use of structural information could be applied in the context of entity-centric environments as well.}, comparing to structural approaches. Despite of further required field studies challenging the applicability of metrics using conceptual information, the concept looks promising and most probably increases also Business-IT alignment, as the idea of agnostic business logic in entity-centric services provides more potential for reuse compared to task-centric services encapsulating operations of a specific business activity \parencite[p. 504]{Rostampour2010}. Metrics based on structural information mostly follow conventional approaches, based on former paradigms.

\begin{table}[ht]
		\begin{center}
	    	\includegraphics[page=22, trim=0cm 2.75cm 11.39cm 0cm, keepaspectratio=true, scale=1, clip=true]{graphics/approach}
			\caption[Collective metrics  overview]{Collective metrics overview in relation to criteria type of information used by the metric (structural or conceptual), architectural element evaluated by metric (system [SOA], service or operation) and source of information (interface [e.g WSDL], service inventory); Column \underline{Table/Figure} lists the figure or table, where the definition of the metric can be looked up in this thesis. Column \underline{Structural / Conceptual} represents the type of information. ``S'' stands for structural, meaning that the information used in the metric originates from structural information of architectural elements (e.g. number of operations in a service). ``C'' represents ``conceptual'', meaning the respective metrics include semantic information to compute its value (e.g. semantic relationship between parameters [business entities] passed in  operations). Column \underline{``SOA / S / O}'' reflects the architectural element (\underline{S} for Service, \underline{O} for Operation) the metric is dealing with. Hence, characteristics on operation, service or (SOA) system-level can be evaluated.  Column \underline{IN / SI} defines the information retrieval of the respective metric. Metrics marked with \underline{IN} take the information out of the \underline{interface} definition (WSDL, etc.), whereas \underline{SI} stands for \underline{service inventory}}
			\label{collective_overview_metrics}
		\end{center}
\end{table}
\noindent
The second criteria considers the applicability of metrics related to  architectural elements. Whereas cohesion makes sense on operation and service level, coupling considers more the service and system-level. This can be underpinned by the fact, that the majority of cohesion metrics (88\%) are applied on operation or service level, whereas the majority of couplingg metrics (86\%) are applied on service or (SOA) system level. Service granularity metrics mostly operate on operation and service level.
\newline
\noindent
Last but not least, the third criteria is about the source of information. This criteria may open a philosophical discussion, whether metrics should be used when evaluating SOM designs of new service candidates, or in the area a governance instruments controlling the compliance of design criteria defined by architects or both. For the former, a service inventory may be in place to evaluate service candidates in relation to productive services. Particularly interesting is, whether inventories cover the required information (such as call graphs of services to detect coupling). The more sophisticated a SOA solution becomes, the more meta information about the services may be stored in a service inventory to be capable of controlling misconceptions. However, coming back to the criteria, all service inventory related metrics require additional information beyond common interface description language capabilities (such as WSDL). Therefore, metrics, whom's information is covered in interface descriptions could be most probably implemented if no service inventory is in place. But to increase the understandability and transparency of a SOA solution, a service inventory makes sense, especially when the SOC environment gets business-critical. Considering the fact, that around 60\% of the overall time devoted for software maintenance \parencite[p. 2]{Karahasanovic2007} is spent with software comprehension. Hence, a service inventory could help to minimize this time and to overall increase the quality of service deliverables in its initial development (as service inventory allows comprehensive service-oriented analysis).
\begin{comment}
\begin{table}[ht]
		\begin{center}
	    	\includegraphics[page=22, trim=0cm 2.75cm 18.48cm 0cm, keepaspectratio=true, scale=1.3, clip=true]{graphics/approach}
			\caption[Collective metrics  overview in relation to field of application and information retrieval (1/2)]{Collective metrics  overview in relation to field of application and information retrieval (1/2)}
			\label{collective_overview_metrics1_2}
		\end{center}
\end{table}

\begin{table}[ht]
		\begin{center}
	    	\includegraphics[page=22, trim=7.12cm 9.16cm 11.42cm 0cm, keepaspectratio=true, scale=1.3, clip=true]{graphics/approach}
			\caption[Collective metrics  overview in relation to field of application and information retrieval (2/2)]{Collective metrics  overview in relation to field of application and information retrieval (2/2)}
			\label{collective_overview_metrics2_2}
		\end{center}
\end{table}
\end{comment}

\subsection{Granularity}
\vspace{-4mm}
Six metrics have been found, whereas four focus on operation level and two on service level. Moreover, found metrics for quantifying service granularity on service level, \textit{G} (defined in figure \ref{FormulasKarthikeyan2012}) requires information beyond the scope of any interface definition language. \textit{G} is supposed to be applied for composite services. Moreover, \textit{CL} could be a good indicator for entity-services to indicate compositions of entity-services and potential performance problems. As previously mentioned, due to the fact that \textit{G} is based on \textit{CL} and \textit{FR}, requiring information about coupled services, a service inventory must be in place. In addition, it could be said, that without having support of a service inventory (or a run-time inventory capable of delivering the required information)  measuring the range (number of inherent functionality) becomes difficult, as by composing multiple services the range is increased, which could not be detected by only having data granularity indicators in place. Moreover, with respect of \textit{IG} and \textit{ODG} the weighting of parameter types must be evaluated, as it could be observed in today's practice that using complex types is more flexible  with respect of ``versioning''. So in fact, weighting of parameters could be different, dependent whether service interaction in a SOA is always based on complex types. In other scenarios, comparing recursively the content of complex types (encoded as XML),  could be more suitable.
\newline
\noindent
However, in \textit{IG} and \textit{ODG} are ideas reflected which could be adjusted to defined guidelines of a SOA projects to have a first indicator about interface granularity in place. Although 
\textit{G} and \textit{SOG} may require as well modifications to be used in practice, these metrics extend the granularity indicator, comparing to the former ones, by adding the range dimension (number of functionality covered by a service), as both metrics take the type and number of operations into consideration. However, to retrieve an absolute measure of service granularity the ideas of G may be followed, as SOG defines granularity on operation level.
\subsection{Cohesion}
\vspace{-4mm}
17 metrics measure cohesion related aspects, whereas the majority (58\%) operates on information defined in the interface itself. It could be stated that a highlevel cohesion evaluation could be implemented based on an analysis of interface definitions (such as WSDLs, etc.). Particularly the conceptual ideas of \textit{$LoC_s$}, \textit{$LoC_c$}, \textit{SFCI} and \textit{SIDC}, which look out for commonalities in input and/or ouptput types or messages defined in the service interface, are promising and useable in practice. However, adjustments might be required to use them in practice, as there are differences in guidelines between SOA projects related the encoding and use of complex types in interfaces. Moreover, some of these metrics come with their prerequeisites, such as \textit{ECF}, \textit{B}, \textit{ICF}, \textit{CCF} and \textit{CCM} require entity-centric process modelling, which therefore affects the overall approach of process decomposition within an enterprise.
With respect of the metrics requiring additional meta-information not covered in a service interface, \textit{LSIC} focuses on implementation cohesion and require additional information about service components used by the service itself. Hence, these metrics focus on internal implementation aspects of services, whereas \textit{SSUC}, \textit{SIUC} and \textit{CUSO} focus on the service provision towards consumers. By means of these metrics usage and sequential cohesion can be quantified. As services, whom's operations are used by every client  seemed to be highly cohesive, these metrics could used to calculate cohesion towards a consumer view.
\subsection{Coupling}
\vspace{-4mm}
With respect to coupling, 23 metrics have been found, whereas eight indicators perform its calculations on the basis of information exposed in interfaces (e.g. WSDL). Three of them (\textit{CCO}, \textit{CDSO}, \textit{CCS}) operate on conceptual information. These indicators are based on the entity-centric approach, which derives semantic information out of interface definitions (relationships between XML elements). In case a SOA initiative has an entity model in place, which is also reflected in the interface, these metrics may deliver strong results in the area of coupling. However, implementing this approach could take its time due to its complexity. Simpler, but efficient in practice seems to be \textit{DCI}, as it measures the number of shared XML schema elements, which store the content of business entities. \textit{DCI} and \textit{SMCI} follow similar ideas, indicating the degree of data coupling among services computed based on the similarity of input and output types of messages. \textit{CL} could be a helpful indicator to outline the number of other services inherently used by a service to fulfill its business logic. Statelessness is addressed by \textit{DPD}, \textit{ARSD}, \textit{DSD}. The suite from \textcite{Hofmeister2008} (\textit{cos}, \textit{SCF}, \textit{SSC}, \textit{EOA}, \textit{SCZ}, \textit{DOA}, \textit{AD}, \textit{ACZ}) proved to be effective to find out mediation and centralization. \textit{SOCI} and \textit{ISCI} can be related to \textit{cos}.